I’ve talked a lot in the past about pros and cons of per-tenant extensions (PTE) in Dynamics 365 Business Central. Despite Microsoft’s guidance (use AppSource) this is actually the most common way for partners to deploy their extensions on a SaaS environment and this is the recommended way for developing specific customizations for a customer tenant.
Unfortunately, the partner’s live with the per-tenant extensions is not so easy nowadays because (in my personal opinion) Microsoft has an internal process for managing PTEs that must be absolutely rethinked. I’ve talked in the past about the main noisy problem with PTEs, but there are other aspects that can cause problems on your tenants.
The problem I want to talk here today is a very noisy problem that I’ve personally experienced this morning on a customer’s SaaS tenant.
I have an extension that adds some fields on the Item List page. As a best practice, if possible I always suggest to add your new fields to a standard list page as last fields of the repeater control on that page.
Our customer has actually an online tenant with platform 13.5 and the new field was added in the following pageextension object:
pageextension 50301 ItemListExt_EID extends "Item List"
{
layout
{
addlast(Item)
{
field("Item with Barcodes"; "Item with Barcodes")
{
ApplicationArea = All;
Editable = false;
Style = Attention;
StyleExpr = attentionStyle;
}
}
}
}
Today I’ve received an email from Microsoft (remember to always add your address in the tenant’s Admin Center email recipients) that says this:
The XXX extension that is installed in the Dynamics 365 Business Central tenant for YYY is not compatible with version 14.0.29537.31665. The compatibility issue must be resolved before the tenant for which the extension is installed can be successfully updated to version 14.0.29537.31665.
Error AL0270: The control ‘Item’ is not found in the target
Why this problem occours? Because I’ve added the Item with Barcodes field (my custom field) as LAST control of the standard repeater control on the Item List page and this repeater control on platform 13.5 was called Item:
On platform 14, Microsoft has renamed the repeater control and this is now called Control1:
Despite the step backward (calling a control like ControlXXX on a page is totally without sense in AL!), what do you have to do now?
You have to download the symbols for the new build and fix your app. For doing this, you have essentially two ways:
- Create a local docker container with the latest official build
- Directly from the online tenant you can create a secondary sandbox with the future version and fix your app by downloading symbols from that sandbox
The fix was simple, just change the repeater control name:
pageextension 50301 ItemListExt_EID extends "Item List"
{
layout
{
addlast(Control1)
{
field("Item with Barcodes"; "Item with Barcodes")
{
ApplicationArea = All;
Editable = false;
Style = Attention;
StyleExpr = attentionStyle;
}
}
}
}
The problem appears if you want to directly upload this extension in the default sandbox environment for releasing the app to your users for testing. Here, platform is again 13.5 and you don’t have Control1 in the Item List page.
If you want to do a fix that permits an immediate publising of this extension for the CURRENT release and that will be compatible for the future release, in this case you need to avoid using ADDLAST(RepeaterName) and add the field AFTER a standard field (ADDAFTER(FieldName)).
Instead, if you want to use ADDLAST(RepeaterName) and upload the fixed extension to the production environment and be ready for the future upgrade, remember that:
- You need to compile the extension for the new build (new symbols)
- Upload the extension for the NEXT MINOR version (not for the Current version as normally you’re doing for every extension):
When you deploy an .app file for the next version, the extension will be queued up and it will be deployed as part of the customer’s tenant upgrade to the next version (so not immediately).
These are noisy aspect, I agree… but actually the platform could have also control names changements between minor releases and you should be aware of that and handle them accordingly.
Stefano Demiliani 
I’m not able to download symbols even with the AL:GO! (al extension 3.0 installed).
I only configure the name and server instance of the launch.json
You know any issue with this?
Thanks
LikeLike
No issue. I suspect you have problems with your launch.json configuration file. Can you post it? What error do you have?
LikeLike
Thanks for your quick reply.
This is my launch
{
“version”: “0.2.0”,
“configurations”: [
{
“type”: “al”,
“request”: “launch”,
“name”: “MyPersonalizations”,
“server”: “https://businesscentral.dynamics.com/xxxxxxxx-9285-d5f6e42d4330/Sandbox2”,
“startupObjectId”: 22,
“startupObjectType”: “Page”,
“breakOnError”: true,
“launchBrowser”: true
}
]
}
The sandbox2 info:
Application version: 14.0.29537.29654
Platform version: 14.1
LikeLike
This launch.json is wrong. If you’re working with an online sandbox, when creating your project with AL:Go! you’ve to select the “Cloud Sandbox” option.
Then, as default VS Code will connect to the default online sandbox for your user. You can specify tenant = “YourTenantID” if you want to connect to a specific online tenant. If you want to connect to another sandbox different than the default one, you can specify sandboxName = “YourSandboxName” in launch.json.
Here, server parameter must not be specified.
LikeLike
Yeah! I dind’t known that now connects directly throw my user.
I have another problem when I try to pusblish the extension in my Sandbox. The compilation ends, but then I have an error. Maybe I have some incorrect configuration….
https://community.dynamics.com/business/f/758/t/318698
Another thing, related to this post. We need to make a codeunit to update the ext per tenant? Or we only have to fix any error caused by new version and the upload with the next major release option?
Thank you so much, there is no much info.
LikeLike
An upgrade codeunit is needed only if you have breaking schema changes and you need to move data from version A to version B. Otherwise no need.
LikeLike
Hi Stefano, Thank you for your post. I guess this small taste of many issues with breaking apps we can expect to get when Microsoft’s refactoring to sub modules really takes of. In your case, then work-around may be to fix it to a field, which exists in both, and move it when upgraded. Definitely not ideal, but that may work.
LikeLike
Great post Stefano.
Thanks for sharing with us.
I have a small query. I got same message regarding upgrade for one of our per-tenant extension, so it can be compatible with upcoming major release.
But there is something confusing me.
I have an extension A that I need to upgrade, but there are other 6-7 extensions , which are dependent on extension A. Now I am confused, if I upgrade my extension A, would it uninstall all other dependent extensions.
Also when I am going to download symbols for this Main Extension A, its saying that it have dependency.
Kindly suggest.
LikeLike
You can upgrade A (change at least the version number), all other extensions will not be uninstalled.
Regarding last question, I’ve not understood…
LikeLike
Thanks for your prompt revert.
My last question was.
Some fields from Extension A being used in Extension B. So I defined dependency of Extension A in Extension B, so that Extension B can download symbols for this dependency.
Now, when I am upgrading Extension A, its saying that it have dependency in Extension B. because some fields from this extension A is being used in B.
But I think , when I upgrading main Extension A, it should not ask to download dependency from inherited Apps.
What you think?
LikeLike
Yes, this is one of the top noisy problem actually with dependency. We currently need to unpublish and uninstall all dependent extensions, before we can publish the main app again.
LikeLike
So for example, if my current version is 1.0.0.0, and I publish changes for Wave2 set to deploy on the “Next minor version” as version 1.0.0.1. Would this mean that i’m blocked from making changes to 1.0.0.0 since there would be a newer version waiting in the queue?
LikeLike
Next minor means next cumulative update on the current release. Next major means next major version (15,16 and so on). Apps for these versions are queued until the version is deployed by MS on the tenant.
LikeLike